> Right; and it's also no better. But it _is_ more complicated. The > magic cookie mechanism is pretty good; if it would allow mutiple > cookies access to the server, or krb5 authentication, we'd have all > the machanism we needed, fairly simply. It is a little better as you don't have to copy arround cookies (usually done in very insecure ways) and all the authentication is done in the X server rather than just trusting anyone who has got a copy of the cookie. You can also revoke a (user,host) pair at the server end once you have finished using that machine. One trick you can do with this is to get the X server to run through all current windows and perform the check again on their existing connection based on the current rules. A server can then flag any connections which wouldn't be valid if they newly connected and kill them. If you wanted to you could do this whenever you changed the rules. Thus if you xhost -jim@dead.com all connections which were authenticated because of that rule would be killed. The actual code to do an Ident based checker is pretty small, not much more than the size of the current cookie checker and generator. Not *much* more complex. I don't see how multiple cookies would help unless you generate a different one for each host and require a (cookie,host) pair to match. This still allows any user who happens to see a (cookie,host) pair (snooped on a 3rd machine say) and has an account on a trusted host to connect to you. A proper encrypted system (like say krb5) could be much better if done well but few vendors seem to support krb. -- Jon Peatfield